As wireless communication becomes more prevalent, many electronic device, especially mobile devices, provide a hardware interface for wireless communication. However, such wireless communication hardware often consumes a disproportionate amount of power, causing the mobile device to require frequent recharging. For example, the battery life of some mobile devices can be halved when using a wireless interface. Generally, efforts directed to decreasing the power consumption of wireless communication hardware have either sought to make the hardware more efficient, or have sought to minimize the amount of time the wireless hardware is in a full-power state.
Wireless communication hardware can enable a mobile device to communicate wirelessly in much the same way that the device would communicate over a wireless connection. Consequently, higher level communication applications, such as email applications, web browser applications, and the like, can use wireless communication just as they would wired communication. However, the device drivers and other software interfacing more directly with the wireless communication hardware can provide wireless-specific functionality to account for the differences between wireless and wired communications. In part, such wireless-specific functionality can be based on predefined standards specifically designed to facilitate wireless communication. Other wireless-specific functionality can include the ability to monitor and adjust wireless signal strength, the ability to provide and use location specific information, and the ability to provide power conservation.
When transmitting data, the higher level communication application can provide the data to lower level software without regard for whether wireless or wired communication is being used. The lower level software, can then prepare the data in the most appropriate manner for transmission via a wireless connection. Often, the lower level software comprises multiple layers. For example, one layer, sometimes referred to as a “transport driver” or a “protocol driver”, can order the data being sent by the higher level application into packets appropriate for a particular network transmission protocol, and can apply headers to each of the packets as called for by the protocol. A further layer, sometimes referred to as an “intermediate driver”, can then provide high level device driver functionality, such as packet filtering or load balancing across multiple physical interfaces. To aid in the development of software to control the network interface hardware itself, a still further layer, sometimes referred to as a “miniport driver” can abstract common functionality. Such a miniport driver can provide functionality common to a particular interface, such as a wireless interface conforming to a particular wireless standard. The miniport driver, in combination with a still further layer, sometimes referred to as a “microport driver”, can provide the necessary control instructions to physically control the communication hardware in order to transmit the data sent by the higher level communication application.
Data that is to be received by the higher level communication application can follow a similar path, except in reverse. Thus, incoming data packets destined for the higher level communication application can be received by the network communication hardware and detected by the miniport/microport driver combination. They can subsequently be passed to the intermediate driver, and then to the transport driver, which can ultimately present the data stream to the higher level communication application. Consequently, because hardware-specific functionality is generally only implemented at the miniport/microport driver layer, efforts at reducing the power consumption of wireless communication hardware have generally been implemented at this level and have exclusively relied on information that can be extrapolated at this level.
Other efforts at reducing the power consumption of wireless communication hardware have been focused on the hardware itself, such as by creating efficient “low-power” states that can listen for appropriate communication, but cannot transmit, thereby reducing power consumption. One difficulty with both of these approaches is that neither of them seek to minimize power consumption from an overall communication system standpoint. For example, while the power consumption of wireless communication hardware can be reduced via the use of low-power states, such states can never be as efficient as a sleep state, in which the hardware neither sends or receives information. However, a hardware solution, by itself, cannot implement such a sleep state, because the hardware can never know when it might need to receive information. Similarly, while the power consumption of wireless communication hardware can be reduced by monitoring the information that can be derived at the lowest driver layers, such information generally does not provide any indication regarding future expected communication, limiting the amount of power consumption that can be saved.